An integration platform supports the modeling and execution of complex integration scenarios, both within the enterprise and externally with remote trading partners. A user will model such an integration using design tools which in turn represent the integration scenario as a set of structured objects with complex inter relationships. The objects representing the integration are stored using a relational database schema to allow for transactional, multiple user access to the scenario. To fully support the life cycle of an integration scenario it is desirable for an integration platform to support versioning of the objects representing integration scenarios.
Versioning of files by source control systems is typically achieved by storing either the first or latest version in completeness and deltas (the differences) to recreate other versions. This is a very space efficient scheme however it is computationally expensive to recreate a particular version. To support versioning of objects stored in a relational database schema is considerably more complicated as the objects have structure and inter-relationships that must be considered as part of the versioning process.
A naive approach to implement versioning for objects stored as rows in database tables would be to clone the row the representing the object. However this leads to issues with object relationship known as the ‘cloning chain reaction’. Consider the example of a department with employees. If a new version of department x is desired, then the row for x is cloned, however the employees related to the previous version of x will not be associated with the new version. Therefore the employees must also be versioned by cloning, even though the requested versioning operation was to version the department. In a more complex object model the cloning would also happen for the other relationships on employee to related objects and so on. Hence versioning a department requires a chain reaction of versioning operations on all related objects. This approach therefore does not allow for fine grain versioning.
Storing of multiple versions of a particular object is described in U.S. Pat. No. 6,460,052 granted to Thomas et al. on Oct. 1, 2002 and entitled “Method and system for performing fine grain versioning”. U.S. Pat. No. 6,460,052 is incorporated by reference herein in its entirety. Specifically, U.S. Pat. No. 6,460,052 states (see Abstract) that a table includes one or more additional columns for storing version information on each object being stored in the table. In response to a request from a user to retrieve a particular object, a version of the particular object to present to the user is automatically determined based on a workspace associated with the user. The version of the particular object is presented to the user without exposing to the user values from the one or more columns in which version information is stored.
According to U.S. Pat. No. 6,460,052 (see column 5, lines 18-26), in one embodiment, each user has a “working context” that defines the set of objects that can be seen by the user. The user accesses the user's working context through a “version resolved view”. The working context of a user defines a set of “configurations” that are associated with the user's workspace. A configuration is a collection of object versions, where each object version in the configuration is for a different object.
U.S. Pat. No. 6,460,052 further states (see column 11, lines 40-50) that when an object is inserted, deleted or updated within a version-resolved view, one or more triggers evaluate access control to determine whether or not the operation can be performed. If the operation is allowed, the triggers of U.S. Pat. No. 6,460,052 construct subordinate SQL that is necessary to insert, delete or update the object within the table, and create the configuration members so that the object can be seen in a subsequent select operation back through the version-resolved view, inserts the object into the current working folder so that it will be seen when navigating the folder, and does the background evaluation of the constraints for generating the corresponding version history information. U.S. Pat. No. 6,460,052 also describes (in column 14, lines 25-45) a set of utilities that automate the process of making software changes.
U.S. Pat. No. 6,460,052, also states (see column 6, lines 14-22) that by providing each user a current working context in which only one version of each object is visible, the database tools can use the repository without having to be aware of the additional complexity that is introduced by version control. In this manner, all work that is performed to track and maintain version information is transparent to the tool. Thus, existing tools that were not designed to support versioning can obtain the benefit of version control without having to be modified.
U.S. Pat. No. 6,460,052 also describes (see column 7, lines 16-25) a table (called “configuration members”) that provides a mapping of configurations to the specific object versions that are associated with the configurations. As previously described, a configuration is a collection of objects that are related in some way that is significant to the user. For example, a configuration may represent all the objects that make up a given component or release. Using the configuration members table, a version control mechanism identifies the specific objects and the specific object versions that make up a particular configuration.
Moreover, the version control mechanism (see column 5, lines 12-21) maintains a user workspace for each user. The user workspace of a user includes an object version of each of the objects that have been “checked-out” by the user. The version control mechanism protects the object versions in a user's workspace from changes by other developers. In one example, each user has a “working context” that defines the set of objects that can be seen by the user. The user accesses the user's working context through a “version resolved view”.
The working context table (see column 7, lines 49-59) defines a list of configuration objects that are currently mapped to a user's workspace. In one example, each user is provided with a private working context. The working space provides a view of those data items that the user is currently working on (“version resolved view”) and protects those data items from being changed by others. A working context may include both structured and non-structured data. Thus, a private working context may include not only file based information but also information that is stored within a table.
Note that when using the methods of U.S. Pat. No. 6,460,052, although a cloning chain reaction is avoided for relationships among first class objects, all objects contained in a first class object are themselves cloned each time the first class object is versioned.
Also incorporated by reference herein in their entirety are the following two articles which disclose first class objects:
(1) an article by S. Ducasse, M. Blay-Fornarino, and A. M. Pinna-Dery, entitled “A reflective model for first class dependencies” published in Proceedings of ACM OOPSLA '95, pages 265-280, 1995, which is available at the URL http://citeseer.nj.nec.com/article/ducasse95reflective.html
(2) an article by S. Ducasse entitled “Inheritance mechanism reification by means of first class object” published in Proceedings of the IJCAI'95 workshop on Reflection and MetaLevel Architectures and their Applications in Al, pages 39-49, 1995, which is available at the URL http://citeseer.nj.nec.com/ducasse95inheritance.html